home *** CD-ROM | disk | FTP | other *** search
/ Columbia Kermit / kermit.zip / e / misc.save / 000040_jaltman2@nyc.rr.com_Fri Dec 22 10:37:24 2006.msg < prev    next >
Internet Message Format  |  2020-01-01  |  3KB
  1. Path: reader2.panix.com!reader1.panix.com!panix!newsfeed.media.kyoto-u.ac.jp!nx02.iad01.newshosting.com!newshosting.com!post02.iad01!roadrunner.com!not-for-mail
  2. Date: Thu, 21 Dec 2006 09:36:47 -0500
  3. From: Jeffrey Altman <jaltman2@nyc.rr.com>
  4. Organization: Send private replies to jaltman at mit dot edu
  5. User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
  6. MIME-Version: 1.0
  7. Newsgroups: comp.protocols.kermit.misc
  8. Subject: Re: Macro: Terminal -> Command -> Terminal -> Command?
  9. References: <xwOhh.34809$cz.516497@ursa-nb00s0.nbnet.nb.ca> <lWShh.32651$tb6.31529@news-wrt-01.rdc-nyc.rr.com> <bF8ih.35271$cz.521966@ursa-nb00s0.nbnet.nb.ca> <4589b00f$0$16922$4c368faf@roadrunner.com> <Gmrih.35742$cz.527501@ursa-nb00s0.nbnet.nb.ca>
  10. In-Reply-To: <Gmrih.35742$cz.527501@ursa-nb00s0.nbnet.nb.ca>
  11. Content-Type: text/plain; charset=ISO-8859-1
  12. Content-Transfer-Encoding: 7bit
  13. Lines: 58
  14. Message-ID: <458a9baa$0$5926$4c368faf@roadrunner.com>
  15. NNTP-Posting-Host: 68.175.93.48
  16. X-Complaints-To: abuse@rr.com
  17. Xref: panix comp.protocols.kermit.misc:15611
  18.  
  19. The value is a "timeout" period not a time-you-must-wait-for period.
  20. You could put 1000 there and it wouldn't make a different provided that
  21. the data you are looking for actually arrives.  The value is "how long
  22. should I wait if the pattern I was given does not find a match on the
  23. incoming data stream?"
  24.  
  25.  
  26.  
  27. Scott Caissie wrote:
  28. > That is what my tests today showed.
  29. > With this, I'll have macros that will be running in a loop for about 50-200 
  30. > times.
  31. > For each, I need only one "INPUT 1" statement at the end to update the 
  32. > screen. Up until that point, using a multitude of INPUT 0s works fine. 1 of 
  33. > my projects will need to update the screen twice.
  34. > I ran one today a few times in a loop of 119 times. Worked perfectly.
  35. > 
  36. > Though I wish you could allow for fractions of a second. Or an instaneous 
  37. > forced update command.
  38. > That would be my wish list for Version 3.0.
  39. > 
  40. > But this so far has helped me a lot. Thanks.
  41. > 
  42. > - Scott
  43. > 
  44. > "Jeffrey Altman" <jaltman2@nyc.rr.com> wrote in message 
  45. > news:4589b00f$0$16922$4c368faf@roadrunner.com...
  46. >> Scott Caissie wrote:
  47. >>> I see. I've been testing this out all day, and it works pretty much the 
  48. >>> way
  49. >>> I was aiming for.  I was never referred to using the INPUT command 
  50. >>> before,
  51. >>> and to be honest, I don't understand it 100% yet. I'm basically mirroring 
  52. >>> my
  53. >>> actions.
  54. >>> I do have a question. Is there restrictions about using INPUT 0 <text>?
  55. >>> This example works fine, but if I use INPUT 0 etc, it won't. I check to 
  56. >>> see
  57. >>> if it works by using \Fscrnstr(y,x,n) on a large scale.
  58. >>>
  59. >>> SET INPUT TERMINAL ON
  60. >>> set input echo off
  61. >>> clear input-buffer
  62. >>> define vega {
  63. >>> ..LZ_PRO := \Fscrnstr(0,6,8)
  64. >>> OUTPUT \5\5\5\5\5\5\5\5\57\49\13\49\52\13\m(LZ_PRO)\24
  65. >>> INPUT 1 \5\5\5\5\5\5\5\5\57\49\13\49\52\13\m(LZ_PRO)\24
  66. >>> for \%t 1 24 1 {
  67. >>> echo \Fscrnstr(\%t,0,79)
  68. >>> }
  69. >>> }
  70. >> If you use "INPUT 0 <text>" you are not reading any data from the
  71. >> connection.  You must use a timeout greater than 0 in order to process 
  72. >> data.
  73. >>
  74. >> Jeffrey Altman 
  75. > 
  76. >